Putting this on hold as I believe that a node core fix is the most appropriate. Buffer can also retain an 8k slab on it's own, ideally node core should emit a buffer that is not backed by any slab.

Agreed

@jmatthewsr-ms is there a bug in the joyent/node that we can follow about this?

Found it: nodejs/node-v0.x-archive#4660

Thanks for the awesome research btw, this is definitely a bit issue we are facing in socket.io and probably engine.io as well.

As this is not being addressed by the Node core team, it seems to me that we need to address this our selfs. What do you think @guille?

I've just run into this issue myself in production and opened up another issue and pull request (#1177 #1178) before finding this issue. If my vote counts for anything, I like the solution here better than my own. It would be nice if this could make it into 0.9, even if you decide on a better solution for 1.0, since we (and many other people) are using Socket.io in production right now and need this fix.

Edit: You can see from the graphs in #1177 that this is quite a serious memory leak in a production server doing large or many requests over HTTPS.

Note that this is being worked on in node core: nodejs/node-v0.x-archive#4964.

The buffer copy in this fix may not be required once node core buffer is fixed. The fix here shouldn't hurt performance if left in, but worth checking once node core is updated.

Hi Everyone, thanks for being on top of this. I had a quick question. I understand that a fix is being worked on node for this and meanwhile japplen's patch has made it into 6e25c80 . We are trying to launch something based on socket.io soon. Can someone please confirm that 6e25c80 fixes the patch being mentioned here.
Thanks

Yes, the patch here has the same effect as 6e25c80. The purpose of both is to dereference the head buffer which is passed to the upgrade event handler since this was the cause of the memory leak.

Thx jpallen :)

Fixing on engine.io (socketio/engine.io#268)